其他
坦白局!网易数帆解读 Apache Kyuubi 1.8 特性
The following article is from Apache Kyuubi Author 潘成
导读 本文主要介绍 Apache Kyuubi 最新版本 1.8 的特性与改进。
本次分享主要分为以下部分:1. Apache Kyuubi 简介
2. 场景扩展 —— 在线分析,离线跑批
3. 流式增强 —— 流批一体,面向未来
4. 企业特性 —— 行业沉淀,持续打磨
5. 开源社区 —— 开放包容,合作共赢
6. 问答环节
分享嘉宾|潘成 网易数帆 大数据技术专家
内容校对|李瑶
出品社区|DataFun
Apache Kyuubi 简介
02
场景扩展 —— 在线分析,离线跑批
spark-submit 会瞬时(持续~30s)消耗大量 CPU 和 IO 资源,突发的高并发任务提交将对 Kyuubi Server 服务所在机器或容器有极高的资源要求; 高并发提交场景下,当单台 Kyuubi Server 出现资源瓶颈时,水平扩容无法快速转移负载到新增节点上; spark-submit 与后续 Application 状态轮训共享线程,spark-submit 仅在初始提交的数十秒内有较大的资源消耗,后续 Application 状态轮训资源消耗极低;使用同一个 Backend 线程池控制线程数从而控制 Batch Session 的并发,无法做到精细化的资源控制:较小的线程数造成单台 Kyuubi 节点承接的 Batch 作业并发度较低;较大的线程数在面临瞬间多个 spark-submit 同时执行时可能发生资源耗尽; 无法做到全局 FIFO 调度和全局优先级调度。
基于数据库的队列:用户向 Kyuubi Server 发起 Batch 任务提交后,入队数据库队列即返回; Submitter 线程池队列:每个 Kyuubi Server 有一个 Submitter 线程池,每个线程专门负责从数据库队列中拾取任务,交由 Backend 线程池做 spark-submit 提交,该线程在 Spark Application 进入 RUNNING 或者退出状态后释放以继续处理数据库队列中的其他任务,从而实现对 spark-submit 进程并发控制; 原有的 Backend 线程池队列:得益于前置 Submitter 线程池对 spark-submit 进程并发度的控制,此线程池可以设置较大的线程数,用于获取对 Spark Application 状态的拉取。
03
流式增强 —— 流批一体,面向未来
04
企业特性 —— 行业沉淀,持续打磨
05
开源社区 —— 开放包容,合作共赢
06
问答环节
HBO,即 History-based Optimization。构建独立的服务,收集并分析任务的特征,对于周期性的调度任务,在任务执行前,基于历史执行信息做出判断,将大查询的会话切换到 CONNECTION 隔离级别,使用独立的计算资源,降低对其他作业的影响。 将选择暴露给用户。例如在 Bilibili 的分享中提到,在面向用户的 SQL 查询工作台中,给出一个“大查询”的选项,对于有一定经验的数据分析师,可以提前预料到自己的查询可能会对 Engine 稳定性造成影响,则主动使用独立的计算资源以规避。
分享嘉宾
INTRODUCTION
潘成
网易数帆
大数据技术专家
Apache Kyuubi PMC Member,Apache Celeborn (Incubating) PPMC Member。
往期优质文章推荐
往期推荐
DataFun
点个在看你最好看